在傳統的軟體測試中，測試員常面臨兩個極端：(1) 僅執行固定的測試案例，導致無法發現非預期的邊界漏洞。(2) 像「尋找鬼魂」般在介面上隨機操作，看似做了很多，實則覆蓋率極低，且一旦找不到缺陷就會陷入迷茫。

Whittaker 提出的漫遊測試（Touring Test）解決了這個問題。他認為一個優秀的測試員應該像「旅遊專家」：既有規劃好的「導覽行程」（確保核心功能穩定），又能保有「隨興探索」的靈活性（發掘隱藏的系統弱點）。

軟體城市的六大區域：

為了便於組織測試路徑，文件將軟體特性劃分為六個相互重疊的區域，每個區域都有其獨特的測試價值：

(1) 商業區 (Business District)
專注於軟體包裝盒上標榜的核心功能，也是用戶購買的主要原因。測試重點會從啟動到關閉的完整業務邏輯，確保「錢花得值得」的功能絕對不能出錯。

(2) 歷史區 (Historical District)
測試的重心在於那些由前版本遺留下來的「代碼古蹟」（Legacy Code），或是曾多次出現漏洞的功能。驗證舊代碼在現代環境下的相容性，並針對那些「惡名昭彰」的區塊進行壓力測試。

(3) 旅遊區 (Tourist District)
針對新用戶非常有吸引力、操作頻繁的熱門功能來進行測試。像是用戶體驗（UX）的流暢度，以及這些功能在短時間內被大量觸發時的穩定性。

(4) 娛樂區 (Entertainment District)
對於軟體的輔助特性、過場動畫或增加趣味性的裝飾功能來測試。確保這些「配角」不會干擾主流程，作為整體測試計劃的補充。

(5) 旅館區 (Hotel District)
關注當軟體處於「休息」、背景運行或等待輸入時的狀態，這些常常被遺忘，但是也是測試的重點。在這裡我們會檢查背景資源佔用、異步處理任務，以及在「閒置」時是否依然忙碌於不必要的進程。

(6) 破舊區 (Bad Neighborhood)
針對代碼混亂、缺乏維護、連開發者都避之唯恐不及的高風險區。這通常是漏洞最集中的地方。測試員必須深入這個充滿「討厭漏洞」的區域，目標是讓缺陷數量降為零。

商業區測試

在多數測試專案的初期，團隊經常會面臨一個看似合理、卻隱含風險的決策：我們應該先從哪裡開始測？有人主張功能清單逐一驗證，有些偏好依模組切分，也有人習慣先從技術風險最高的地方下手。

這些策略都沒有錯，但在實務現場中，我們很快就會發現一個現象：即使測試覆蓋率看似完整，系統上線後仍然會在某些地方頻繁出現事故，而且往往集中在少數幾條流程。

那些出問題的地方，並不是最複雜的演算法，也不是最冷門的設定頁，而是使用者每天會走、每分鐘都有人在操作的核心路徑。這些區域，我們可以把它想像成一座城市裡的「商業區」。

為什麼用商業區來比喻？城市的商業區有幾個明顯特徵：

• 人潮密集。早晚通勤時間與午餐時段最為擁擠，因為人們會在這裡完成工作、交易與決策。
• 容錯率極低。捷運停擺、銀行系統故障、支付失敗，都會立即造成大規模影響。
• 它直接關係到城市的運作與收入。商業區若停擺，整座城市都會失去活力。

軟體系統其實也存在類似結構。有些功能像住宅區，存在但不常被觸發；有些像公園，美觀但非必要；而另一些則是人潮最密集、價值最集中的區域，使用者必須依賴它們才能完成任務。這些地方，就是商業區。

若以台灣高鐵訂票系統為例，商業區並不難辨認。使用者進入系統，目的非常單純就是想要買到一張票。因此，整個價值鏈會集中在幾個關鍵節點：

• 查詢班次與日期。
• 選擇車廂與座位。
• 決定購買張數。
• 填寫乘車資訊。
• 完成付款。
• 取得票券或 QR Code。

只要其中任何一個節點出現阻塞，使用者的任務就會中斷。他們不會覺得系統「有點不好用」，而是會直接感知為「我買不到票」。因此，商業區測試的核心精神並不是追求全面，而是優先確保這些高價值路徑的穩定與可信。

(1) 指南測試法

在辨識出商業區後，測試人員第一條常走的路線，往往是所謂的「指南測試法」（Guidebook Tour）。這個方法的概念，源自於旅遊情境。多數旅客抵達陌生城市時，並不會完全依賴直覺探索，而是會先翻閱旅遊手冊、官方指南或推薦路線。這些資料告訴他們：哪裡最值得去、如何抵達、什麼時間點最適合。

同樣地，軟體系統也提供大量「指引」：使用手冊、操作說明、線上 Help、FAQ、甚至 UI 上的提示文字。指南測試法的出發點在於這些文件不只是輔助資料，而是系統對使用者做出的承諾。測試的任務，就是驗證這些承諾是否真實存在。

以高鐵訂票系統為例，官方會清楚說明預訂規則：

• 旅客可預訂 29 天內車次。
• 發車前 1 小時截止訂票。
• 週五與週六可預訂至四週後週日。

這些文字在文件中看似明確，但當測試者開始以指南路線操作時，問題便會逐漸浮現。

• 第 29 天的計算基準為何？
• 跨日凌晨是否仍算有效？
• 發車前 60 分鐘與 59 分鐘之間如何判定？
• 系統是否提供即時提示避免誤解？

當文件描述與系統行為之間出現任何差距，使用者就會陷入不確定狀態，而這往往比單純功能錯誤更具破壞力。

A. Blogger’s Tour：當使用者不是看手冊，而是看別人怎麼用

在探索式測試的各種導覽路線中，Blogger’s Tour 往往是一條很貼近真實世界、卻容易被測試團隊忽略的路線。它的出發點其實很簡單：多數使用者第一次接觸一個系統時，並不會去翻官方文件。他們更常做的事情是打開搜尋引擎，輸入幾個關鍵字：

「怎麼搶高鐵票」
「高鐵選位技巧」
「高鐵信用卡優惠訂票教學」

接著，他們會點進部落格文章、論壇整理文，或是 YouTube 教學影片，然後照著畫面一步步操作。

這些內容，雖然不是官方指南，卻在實務上扮演了「非正式使用手冊」的角色。對許多新手使用者而言，它們甚至比官方文件更容易理解，也更值得信任。

Blogger’s Tour 的測試視角，正是從這裡誕生。如果要用一句較為精準的方式來描述，Blogger’s Tour 可以被理解為：依循第三方教學或經驗分享的操作路徑，驗證系統是否仍支援這些被廣泛採用的使用方式。

這裡的重點不在於教學內容是否正確，而在於當大量使用者依賴這些路徑時，系統是否仍能順利支撐他們完成任務。換句話說，測試的不只是功能，而是「被社群傳播後的真實使用流程」。

表面上看，這方法像是在測「教學是否過時」。但更深層來說，它測的是三件事：

第一，系統改版是否考慮既有使用習慣。
第二，外部知識是否仍能被系統支撐。
第三，新手學習曲線是否被流程變動破壞。

這些議題若被忽略，系統即使功能完整，仍會被認為難以上手。

B. Pundit’s Tour：從評論與抱怨裡，挖出真正的風險地帶

如果說 Blogger’s Tour 關注的是「別人怎麼教你用系統」，那麼 Pundit’s Tour 則是另一個更貼近現實、也更帶情緒的入口：它關注的不是教學，而是評論。更精確地說，是從使用者評論、抱怨與批判性觀點出發，還原其操作情境，並驗證系統是否存在可重現的體驗或流程缺陷。

為什麼叫 Pundit？“Pundit” 原意指的是評論者、意見領袖、觀察家。放在軟體世界裡，可以理解為：

• 論壇發文的人。
• App 商店留一星評論的人。
• 社群裡長篇抱怨流程的人。

他們未必是系統專家，也未必完全客觀，但他們往往是「踩過痛點的人」。而探索式測試裡的 Pundit’s Tour，就是把這些聲音當成測試線索。

這裡的關鍵不是評論是否精準，而是評論背後是否存在可被驗證的系統風險。因為多數抱怨，不會憑空出現。

為什麼評論值得被測試？在正式測試流程裡，我們常依據需求文件、設計規格、驗收條件來設計案例。但真實世界的使用者，並不是照規格操作。他們會：

• 在訊號最差的地方付款。
• 用兩台裝置同時操作。
• 臨時改行程。
• 在最後一分鐘才變更。

這些行為，很少被完整寫進需求，但卻經常出現在評論區。因此，評論其實是一種「非正式缺陷回報系統」。只是語氣比較激烈而已。

C. Competitor’s Tour：當使用者不是第一次用「訂票系統」

當我們談探索式測試時，很容易把注意力集中在「系統本身」，係上功能是否正確、流程是否順暢、文件是否清楚。

但真實世界裡，多數使用者在使用一個系統時，並不是從零開始學習。他們早就用過別的系統。也就是說，他們帶著既有經驗走進來。這些經驗，會在無形之中形成一種期待。而 Competitor’s Tour，正是從這種「被市場塑造的期待」出發。

若要用一個較精準的定義來描述，Competitor’s Tour 可以理解為：以競品系統的操作模式與使用習慣為參照，檢視本系統在流程設計、資訊揭露與任務完成體驗上的落差與風險。

這裡的重點不在功能多寡，而在體驗合理性。因為使用者不會拿需求文件來比較系統。他們只會憑感覺說一句話：「別的系統就不會這樣。」

為什麼競品視角對測試重要？原因很簡單。當一個使用者同時使用多個訂票平台時，他的大腦會自動建立「操作模型」。例如：

• 付款前應該看到完整金額。
• 變更時應該有差額試算。
• 多人票券應該能個別管理。

當這些模型被建立後，任何偏離都會被放大。即使你的系統功能完全正確，只要違背使用者既有習慣，就會被視為設計缺陷。因此，Competitor’s Tour 測試的，其實是市場對流程合理性的共識。

因此Competitor’s Tour 很少找到「功能錯誤」。它更常揭露的是三種落差：

流程揭露節奏落差。
決策資訊透明度落差。
任務完成彈性落差。

這些落差不會讓系統壞掉，但會讓使用者覺得系統落後、不直覺、甚至不可信。而在商業區流程中，「不信任」往往比「錯誤」更致命。